DXL Attribute UUID

Hi everyone,

I am trying to create a script that generates a UUID for an object attribute. The UUID is only created, if the "Object Level" has a certain value (in this case 3).

Problem: If I run the script in the "Edit DXL" runner everything works fine. But if I add the below script into the "DXL Attribute" by adding a new Attribute to the module, DOORS crashes without any hint on what happened. It would be create if someone could help me, as I dont see any scripting errors (though I am new to DXL programming in DOORS).

I proceeded as follows:

Pre: Module is open with some data in it

1. Edit Attributes

2. Create new Text Attribute -> Select DXL Attribute -> Current -> Paste my Script in there -> 0 Errors

3. As soons as I hit "close" in the Edit Dialog, DOORS crashes

===== Script =====

//createTestCaseID


const string TC_ID = "testcase_id"

//createGUID
//==========
//create a UUID by calling UUID on a new OLE Object of Prog ID
//"Scriptlet.TypeLib".
//Parameters:
//none
//returns:
//An UUID
//
string createGUID()
{
    //Must create "Scriptlet.TypeLib" anew for each new UUID required.
    //Otherwise it returns always the same UUID
    //Method "Reset" has no effect.
    OleAutoObj oleTLB = oleGetAutoObject("Scriptlet.TypeLib")
    if (null oleTLB){
        oleTLB = oleCreateAutoObject("Scriptlet.TypeLib")
    }

    string uuid
    oleGet(oleTLB, "GUID", uuid)
    return lower(uuid[1:36])
}

Object o = current

int level = level(Object o)

if (level == 3){
    string abc = o.TC_ID ""
    if (null(abc) || length(abc) == 0){
        
        string uid = createGUID()
        o.TC_ID = uid
        print uid
    }
}


MichaelMN - Fri May 24 05:49:06 EDT 2013

Re: DXL Attribute UUID
GregM_dxler - Fri May 24 11:02:44 EDT 2013

Hello,

One obvious thing is using the print command.  The print command will try to print the value in the edit dxl window.  If the window is not there, it may be why it is crashing.  I haven't worked with dxl attributes much, but have worked layout dxl scripts.

The Object o = current is not needed, since the dxl attribute script only works on one object.  "obj" is already predefined as an object to use in dxl attributes and layout dxl's.  I don't think this would make it crash.

I'm assuming that the "testcase_id" attribute is already defined?

Hope this helps,

Greg

Re: DXL Attribute UUID
llandale - Fri May 24 12:37:17 EDT 2013

As for Greg's reply:

  • Object o = current is wrong, not just "not needed".
  • Yes use pre-defined variable "obj", which means "this object" in Attr and Layout DXL.
  • No, "print"ing will display the DXL output window.

As for your code in general:

When you "close" the Attr dialog, the attribute you just created is added to the view and therefore the code runs.  DOORS is crashing no doubt because you have deployed the code in attribute "testcase_id", and the code reads the value of that attribute which fires the attr-dxl in a vicious circle.

It appears what you are trying to do is set the Test case only for objects that don't already have one.  If so, Attr-DXL is a poor choice of medium because you want to SAVE attr-values for future display, and attr-DXL values are not saved at all.

But if you INSIST on attr-DXL, you can do the following which is a bit hokey.  the main problem is when the values are accessed when the module is open Read, then your "Scriptlet" interface will fire now, and also the next time the value is accessed.  I wonder if that is tolerable.  Instead, you only get a refreshed UUID when the module is open Edit.

  • Create attribute "testcase_id_Hold" type string
  • Create attr-DXL "testcase_id" and deploy the code therein (as modified below)
  • Put attr "testcase_id" in the views; advise users to ignore "testcase_id_Hold"
  • //createTestCaseID
  •  
  • const string TC_ID = "testcase_id"
  • //createGUID
  • //==========
  • //create a UUID by calling UUID on a new OLE Object of Prog ID
  • //"Scriptlet.TypeLib".
  • //Parameters:
  • //none
  • //returns:
  • //An UUID
  • //
  • string createGUID()
  • {
  •     //Must create "Scriptlet.TypeLib" anew for each new UUID required.
  •     //Otherwise it returns always the same UUID
  •     //Method "Reset" has no effect.
  •     OleAutoObj oleTLB = oleGetAutoObject("Scriptlet.TypeLib")
  •     if (null oleTLB){
  •         oleTLB = oleCreateAutoObject("Scriptlet.TypeLib")
  •     }
  •     string uuid
  •     oleGet(oleTLB, "GUID", uuid)
  •     oleCloseAutoObject(oleTLB)
  •     return lower(uuid[1:36])
  • }
  • int level = level(obj)
  • if (level == 3 and canModify(obj)){
  •     string abc = obj.TC_ID ""
  •     if (null(abc) || length(abc) == 0){
  •        
  •         string uid = createGUID()
  •         obj.TC_ID = uid
  •        // print uid
  •     }
  • }
  • obj.attrDXLName = obj.TC_ID ""

Didn't try to run the code; you may need to debug it.

-Louie

How did you post your original code?

Re: DXL Attribute UUID
MichaelMN - Mon Jun 03 06:24:37 EDT 2013

llandale - Fri May 24 12:37:17 EDT 2013

As for Greg's reply:

  • Object o = current is wrong, not just "not needed".
  • Yes use pre-defined variable "obj", which means "this object" in Attr and Layout DXL.
  • No, "print"ing will display the DXL output window.

As for your code in general:

When you "close" the Attr dialog, the attribute you just created is added to the view and therefore the code runs.  DOORS is crashing no doubt because you have deployed the code in attribute "testcase_id", and the code reads the value of that attribute which fires the attr-dxl in a vicious circle.

It appears what you are trying to do is set the Test case only for objects that don't already have one.  If so, Attr-DXL is a poor choice of medium because you want to SAVE attr-values for future display, and attr-DXL values are not saved at all.

But if you INSIST on attr-DXL, you can do the following which is a bit hokey.  the main problem is when the values are accessed when the module is open Read, then your "Scriptlet" interface will fire now, and also the next time the value is accessed.  I wonder if that is tolerable.  Instead, you only get a refreshed UUID when the module is open Edit.

  • Create attribute "testcase_id_Hold" type string
  • Create attr-DXL "testcase_id" and deploy the code therein (as modified below)
  • Put attr "testcase_id" in the views; advise users to ignore "testcase_id_Hold"
  • //createTestCaseID
  •  
  • const string TC_ID = "testcase_id"
  • //createGUID
  • //==========
  • //create a UUID by calling UUID on a new OLE Object of Prog ID
  • //"Scriptlet.TypeLib".
  • //Parameters:
  • //none
  • //returns:
  • //An UUID
  • //
  • string createGUID()
  • {
  •     //Must create "Scriptlet.TypeLib" anew for each new UUID required.
  •     //Otherwise it returns always the same UUID
  •     //Method "Reset" has no effect.
  •     OleAutoObj oleTLB = oleGetAutoObject("Scriptlet.TypeLib")
  •     if (null oleTLB){
  •         oleTLB = oleCreateAutoObject("Scriptlet.TypeLib")
  •     }
  •     string uuid
  •     oleGet(oleTLB, "GUID", uuid)
  •     oleCloseAutoObject(oleTLB)
  •     return lower(uuid[1:36])
  • }
  • int level = level(obj)
  • if (level == 3 and canModify(obj)){
  •     string abc = obj.TC_ID ""
  •     if (null(abc) || length(abc) == 0){
  •        
  •         string uid = createGUID()
  •         obj.TC_ID = uid
  •        // print uid
  •     }
  • }
  • obj.attrDXLName = obj.TC_ID ""

Didn't try to run the code; you may need to debug it.

-Louie

How did you post your original code?

It appears what you are trying to do is set the Test case only for objects that don't already have one.  If so, Attr-DXL is a poor choice of medium because you want to SAVE attr-values for future display, and attr-DXL values are not saved at all.

Thanks for the answers. As you said, I am trying to only save the ID/UUID, if a certain object level is reached and the ID is not already calculated. Though as for your solution; I'll try it out as soon as I get myself some playtime with Doors ;)

Is there any other way to define IDs for Attributes in Doors? I am trying to document the test specification of our software, which is linked with the jUnit TCs in eclipse via this ID. But in order for this to work, the TC ID has to be static.

Regards

Mike

Re: DXL Attribute UUID
BillTidy - Mon Jun 03 07:28:15 EDT 2013

I'm not really sure what you're trying to do.

jUnit can generate unique ids for your tests. You then need to match your jUnit tests with the requirements in DOORS. Either in DOORS or in your test environment you need to hold both the DOORS ID (Absolute Number) of the requirement and the Unique id of the test. It's probably easiest to hold this in your test environment and make the mapping there (say which requirement a test is covering).

When you need to feed this info to DOORS, then send the info you need from your jUnit environment (at least the DOORS ID and jUnit ID) to a DOORS module - make it a different DOORS module than your requirements with columns like "Req ID" and "jUnit ID".  Note: When you import that data into DOORS, "jUnit ID" is your unique id attribute. Then link the 2 modules using link by attribute and the"Req ID" you imported from your test tool.

Re: DXL Attribute UUID
MichaelMN - Mon Jun 03 09:50:15 EDT 2013

BillTidy - Mon Jun 03 07:28:15 EDT 2013

I'm not really sure what you're trying to do.

jUnit can generate unique ids for your tests. You then need to match your jUnit tests with the requirements in DOORS. Either in DOORS or in your test environment you need to hold both the DOORS ID (Absolute Number) of the requirement and the Unique id of the test. It's probably easiest to hold this in your test environment and make the mapping there (say which requirement a test is covering).

When you need to feed this info to DOORS, then send the info you need from your jUnit environment (at least the DOORS ID and jUnit ID) to a DOORS module - make it a different DOORS module than your requirements with columns like "Req ID" and "jUnit ID".  Note: When you import that data into DOORS, "jUnit ID" is your unique id attribute. Then link the 2 modules using link by attribute and the"Req ID" you imported from your test tool.

Hi BillTidy,

I aggree. This would be the process using the test environment as your "baseline" for generating the test case ID. What I am trying to achieve is as follows:

  • Doors as source to specify test cases (pre,action,post). I want the programmer to first design the test case before implementing it. Also this would enable colleagues without the test environment access to specify test cases.
  • Doors generating unique ID for each test case
  • Exporting Doors test specifcation to Eclipse as jUnit structure. Already got a parser generating packages/classes and methods represting the test specification structure.

Only problem so far was generating the ID. I am also not really satisfied using a UUID as test case identifier since it is quite long. Rather I would love a ID generator/script of some sort.

Another goal is, as you already pointed out, to link all the test cases within the test specification to the requirements, in order to document the requirement test coverage.

Hope I could explain, what I am trying to accomplish ;) I am not sure if Doors is the right way, but for now it is the easiest (and cheapest as we got floating licences).

Regards

Mike

Re: DXL Attribute UUID
BillTidy - Mon Jun 03 14:10:36 EDT 2013

MichaelMN - Mon Jun 03 09:50:15 EDT 2013

Hi BillTidy,

I aggree. This would be the process using the test environment as your "baseline" for generating the test case ID. What I am trying to achieve is as follows:

  • Doors as source to specify test cases (pre,action,post). I want the programmer to first design the test case before implementing it. Also this would enable colleagues without the test environment access to specify test cases.
  • Doors generating unique ID for each test case
  • Exporting Doors test specifcation to Eclipse as jUnit structure. Already got a parser generating packages/classes and methods represting the test specification structure.

Only problem so far was generating the ID. I am also not really satisfied using a UUID as test case identifier since it is quite long. Rather I would love a ID generator/script of some sort.

Another goal is, as you already pointed out, to link all the test cases within the test specification to the requirements, in order to document the requirement test coverage.

Hope I could explain, what I am trying to accomplish ;) I am not sure if Doors is the right way, but for now it is the easiest (and cheapest as we got floating licences).

Regards

Mike

If you want to use DOORS as the master data source for your test cases then use the id generated by DOORS - it is guaranteed unique. There's no need for you to write any code to generate a unique id when that's available in DOORS already.

Have 1 module in DOORS for your requirements and 1 module for test cases. You create links between the objects (rows) in the test case module and objects (rows) in the requirements module. Each module generates unique ids by default in DOORS. That's it.

Re: DXL Attribute UUID
llandale - Tue Jun 04 12:24:22 EDT 2013

BillTidy - Mon Jun 03 07:28:15 EDT 2013

I'm not really sure what you're trying to do.

jUnit can generate unique ids for your tests. You then need to match your jUnit tests with the requirements in DOORS. Either in DOORS or in your test environment you need to hold both the DOORS ID (Absolute Number) of the requirement and the Unique id of the test. It's probably easiest to hold this in your test environment and make the mapping there (say which requirement a test is covering).

When you need to feed this info to DOORS, then send the info you need from your jUnit environment (at least the DOORS ID and jUnit ID) to a DOORS module - make it a different DOORS module than your requirements with columns like "Req ID" and "jUnit ID".  Note: When you import that data into DOORS, "jUnit ID" is your unique id attribute. Then link the 2 modules using link by attribute and the"Req ID" you imported from your test tool.

 It's probably easiest to hold this in your test environment and make the mapping there (say which requirement a test is covering).

I think that is excellent advise.  Usually the Req comes first and the Tests come later, and the Test folks decide which Tests exist and which Reqs they test. Often, Reqs specs are locked down which discourages puting Test info in them. Generally, in DOORS, then the Tests Procedures link to the Requirements they test.  Then you can have an Attr-DXL in the Req module that lists the IDs of the in-linked Test IDs; and likewise the Test Module can have an attr-DXL showing the Identifiers of out-linked Requiements.

-Louie